Cryptographic
keys and passwords that protect keys are not a "set-it-and-forgetit"
feature of securing sensitive data; they require periodic maintenance
to ensure that the items that are protected remain at their highest
level of security. Regular maintenance of keys and passwords reduces
the occurrences of the patterns of encryption being discovered through
the monitoring of encrypted values, a practice called crypto-analysis.
It reduces the occurrences of key fatigue, in which bits of plain text
begin to appear among the cipher text. In the unfortunate situation
when a key is revealed, improperly disclosed or lost, the scope of the
compromised data is reduced if the entire body of sensitive data is not
protected with the same key.
This maintenance is handled by shepherding each key through a lifecycle, illustrated in Figure 1,
which defines when a key is created, used for the first time in
encryption and decryption, expired for encryption purposes, retired
from use and finally eliminated.
Other than providing a means
to create new keys and regenerate encrypted data with a new key, SQL
Server does not offer a built-in means to manage keys through this
lifecycle. At first glance, this may seem to be a bad oversight but, in
fact, provision of key management functionality within the database
that contains the encrypted data and keys introduces a potential
vulnerability in data security.
Extensible Key Management (SQL Server 2008)
To address the maintenance issue, SQL Server 2008 introduced functionality called Extensible Key Management (EKM). Through the Microsoft Cryptographic API
(MCAPI) provider, this feature offers the ability to implement a third
party solution, or even a custom built solution, for generating,
backing up, exporting, distributing, retrieving keys and managing the
overall key lifecycle externally from the database. EKM also enables
use of devices such as Hardware Security Modules (HSM), smartcards, and fingerprint readers to store, configure and manage key lifecycles.
MCAPI
cryptographic providers can be created in SQL Server through the
execution of the CREATE CRYPTOGRAPHIC PROVIDER command, as shown in Listing 1. The .dll file provided in this example represents a third party product that would be used for key management functionality.
You can query sys.cryptographic_providers to verify that the provider was successfully created.
The use of EKM, by default, is
disabled. To begin to use this feature of SQL Server you will need to
first execute the script in Listing 2.
Once the cryptographic
providers have been created and EKM is enabled these keys can be
utilized to perform encryption and decryption of other keys and data
through the standard built-in cryptographic functions that are provided
with SQL Server.
Backing up Keys
Whenever the topic of
encryption is being discussed there is a question that inevitably
arises. This question is in regard to how encrypted data can be
recovered if the key is lost or corrupted. The answer is a short one:
the data will be lost. That is unless you have backed up all of the
keys that are used in the encryption effort.
When the database is backed
up through the built-in SQL Server database back up process, some keys
are included in the back up file and others are not. The asymmetric
keys and symmetric keys that are created within the database, as well
as the database encryption key that is used in the TDE feature, are all
included in the database backup. The service master key, database
master key and certificates are not included in the database backup.
Each of these keys must be backed up as a separate task, using the
following commands:
Each of these commands contains an ENCRYPTED BY PASSWORD option which protects the backup files with the defined password, as shown in Listing 3.
To recover these keys, knowledge of this password is required.
It is highly recommended
that these key backup files are stored on separate media from the
database backup files so that, in the event that the media that
contains the database backup files is stolen or compromised, the data
contained within the database remains secured. The decryption of the
data and files contained in the backup media would require access to
the backup media that contained the key backup files.
